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(54) Virtual private network management 

(57) The invention provides a centralized VPN man- 
agement of a plurality of VPN sites by means of a VPN 
Information Provider (VIP) (400, 401). Management of 



a VPN device is distributed so that at least part of the 
VPN configuration is centrally managed without giving 
away control of the firewall rulebase or other critical local 
configuration used in the VPN device. 
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Description 

BACKGROUND OF THE INVENTION 

[0001] The invention relates in general to Virtual Pri- 
vate Networks (VPN). In particular the invention relates 
to managing VPNs. 

[0002] Public networks are presently being used more 
and more for sensitive and mission critical communica- 
tions and the internal networks of various organisations 
and enterprises are nowadays connected to the public 
networks, Internet being one of them. Since the basic 
mechanisms of the public networks were originally not 
designed with secrecy and confidentiality in mind, public 
networks are untrusted networks. 
[0003] Virtual Private Networks (VPN) are commonly 
used for connecting trusted parties to each other over 
untrusted public network through a secure tunnel. All 
traffic from a first party to a second party is encrypted in 
a security gateway of the first party, sent in encrypted 
form over the public network to the second party, where 
the transmitted data is decrypted in a security gateway 
and the decrypted data is forwarded to the recipient. The 
VPN is typically transparent to the processes that are 
communicating between each other and the encryption 
and decryption depend on the configuration of the VPN 
between the parties. However, the security gateways 
need to have information about the configuration of the 
other end of the VPN in order to be able to encrypt and 
decrypt the traffic correctly. The configuration includes 
things like addressing, encryption algorithm and key in- 
formation of the other end security gateway. The config- 
uration information is usually conveyed between the ad- 
ministrators of different sites by means of phone or 
some other traditional communication system. The ad- 
ministrators then input the configuration to the security 
gateways of their sites in order to enable VPN connec- 
tions between the sites. The actual encryption keys are 
exchanged in VPN communication, but the configura- 
tion that is needed for initiating VPN connection needs 
to be conveyed by some other means. 
[0004] Large VPNs are complicated and tedious to 
manage. Keeping the information about the structure of 
the VPN up to date at each site (network or group of 
networks connected to the VPN) is problematic but man- 
datory. Every site must have the correct configuration 
for all the other sites in order to communicate with them. 
In large VPNs there may be dozens or hundreds of sites 
and the configuration may vary in time rather frequently, 
and If the configuration of one VPN site changes all sites 
need to be updated. That is, the administrator of the 
sites changing its configuration needs to contact admin- 
istrators of all other sites and communicate the changes 
to them, whereby they need to re-configure their security 
gateways. 

[0005] Figure 1 illustrates an example network topol- 
ogy with four sites 101-104, who are able to communi- 
cate with each other by means of VPNs. The sites 
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101-104 are connected to the Internet 100 via security 
gateways 105-108. Each security gateway is managed 
via a site-specific management server 109-112, which 
usually resides inside respective site and to each site 

5 there is configured VPN configuration information of all 
other sites as well as the configuration of the site itself. 
In case the security gateway functions as a firewall; the 
firewall configuration (access rules) of the security gate- 
ways is naturally not duplicated to the other sites. 

10 [0006] One proposal for managing large VPNs is a 
star like VPN, where a central "hub" acts as a VPN rout- 
er. Each site connects to the hub, which decrypts the 
packets and then re-encrypts them for the connection 
from the hub to the target site. This way, the VPN sites 

15 do not need to have up-to-date VPN information of all 
other sites; instead it is enough to be able to connect to 
the central hub. 

[0007] Figure 2 illustrates the network topology of Fig- 
ure 1 in connection with the star like VPN. The sites in- 

20 elude now only VPN configuration of the site itself and 
of a central hub 200. The central hub includes VPN con- 
figuration of all the sites in the configuration, and the 
sites connect to each other via the central hub. 
[0008] The disadvantage of the star like VPN is that 

25 vast amounts of processing power are required at the 
hub. The security gateway at each site still has the same 
amount of encryption load as in a standard distributed 
VPN, but the hub's load is in fact equal to the sum of the 
loads of all the sites. In large-scale VPNs this may be 

30 difficult or impossible to achieve and in any case very 
expensive. Furthermore, the data transmitted in the 
VPNs is in cleartext form within the hub, which is clearly 
a security risk. 

[0009] If all the sites belonging to a VPN belong to the 
35 same organization, it is possible to administer them cen- 
trally by means of existing tools. In this case, all aspects 
of the security gateways, including access control con- 
figuration, are managed from one central point. Howev- 
er, the sites joining a VPN are not always sites of one 
40 party, but many different organizations may wish to es- 
tablish a VPN between them. Clearly, such central man- 
agement of all aspects of security gateways is not suit- 
able, if different organizations are involved. Therefore a 
new way to manage VPNs of more than one organisa- 
45 tion and especially large VPNs is required. 

SUMMARY OF THE INVENTION 

[001 0] An object of the invention is to provide a meth- 
50 od for managing VPN devices, which avoids or allevi- 
ates the problems mentioned above. The object is 
achieved according to the invention as disclosed in the 
attached independent claims. Preferred embodiments 
of the invention are disclosed in the dependent claims. 
55 The features described in one dependent claim may be 
further combined with features described in another de- 
pendent claim to produce further embodiments of the 
invention. 
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[0011] The idea of the invention is to provide a cen- 
tralized VPN management of a plurality of VPN sites by 
means of a VPN Information Provider (VIP). The secu- 
rity gateway (or other VPN device) management is dis- 
tributed so that at least part of the VPN configuration 
(especially the part consisting of site addressing, used 
encryption algorithms and key management) is centrally 
managed without giving away control of the firewall rule- 
base or other critical local configuration used in the se- 
curity gateway. There may be several VPNs handled by 
different VIPs, so that an organization using the inven- 
tion can flexibly join several independent VPNs. 
[0012] The VIP according to the invention is a mutu- 
ally trusted party, from which the parties joining a VPN 
are willing to accept configuration information. 
[0013] According to a first aspect of the invention a 
method for managing VPN devices comprises 

- maintaining in a VPN Information Provider (VIP) 
VPN configurations of VPN devices belonging to a 
first VPN, 

providing from the VIP to a first VPN device belong- 
ing to the first VPN, VPN configuration of at least 
one other VPN device belonging to the first VPN, 
and 

managing certain aspects of said first VPN device 
belonging to the first VPN from at least one other 
management system. 

[0014] According to a second aspect of the invention 
a method for managing VPN device comprises 

maintaining in a first VPN Information Provider 
(VIP) VPN configurations of VPN device belonging 
to a first VPN, 

maintaining in a second VPN Information Provider 
(VIP) VPN configurations of VPN device belonging 
to a second VPN, and 

providing to a first VPN device belonging to the first 
and second VPNs, VPN configuration of at least 
one other VPN device belonging to the first VPN 
from the first VIP and VPN configuration of at least 
one other VPN device belonging to the second VPN 
from the second VIP. 

[001 5] The configuration of at least one other VPN de- 
vice may be provided directly to said first VPN device or 
via at least one other management system. 
[001 6] Own VPN configuration of a given VPN device 
may be defined in the VIP or in some other management 
system, from where the configuration is provided to the 
VIP for maintenance. 

[001 7] Providing the configu ratio n(s) of other VPN de- 
vices to a VPN device may be done by sending to a first 
VPN device belonging to the first VPN, information 
about the VPN configurations maintained in the VIP, and 
by requesting from the first VIP VPN configuration of an- 
other security gateway belonging to the first VPN when 



needed. Said information about the VPN configurations 
maintained in the VIP may be for example a set of ad- 
dresses included in the first VPN. (The set of addresses 
may be a single address range or plurality of address 

5 ranges related to different sites included in the VPN.) In 
that case, the request from the first VPN device com- 
prises an address included in the first VPN, and said 
other VPN device is identified in the VIP by finding a 
VPN device related to said address. Said information 

10 about the configurations - that is, the set of addresses - 
may be sent to the VPN devices after a change in the 
set of addresses included in the first VPN, or after a pre- 
defined time has elapsed since the information was sent 
the last time. 

15 [0018] Alternatively the VIP may send, to VPN devic- 
es belonging to the first VPN, VPN configurations main- 
tained in the VIP, so that the configurations are readily 
available in the VPN devices when needed. The VPN 
configurations maintained in the VIP may be sentfor ex- 

20 ample after a new VPN configuration has been added 
to the VIP, after an old VPN configuration has been re- 
moved from the VIP, after a VPN configuration of at least 
one VPN device has been changed in the VIP, or after 
a predefined time has elapsed since the configurations 

25 were sent the last time. That is, all changes need to be 
instantly conveyed to the VPN devices. 
[001 9] In either of the above cases, the VIP may send 
only changes or additions to the information or configu- 
rations previously sent (an incremental update) or all 

30 available information or configurations (a full update). 
[0020] According to a third aspect of the invention a 
method for handling VPN configuration in a VPN device 
comprises 

35 - receiving a packet directed to a destination address 
in a first VPN, 

requesting and receiving VPN configuration for a 
VPN device related to said destination address from 
a VPN Information Provider (VIP) administering the 
40 first VPN, and 

using said VPN configuration for establishing a VPN 
tunnel to said VPN device related to said destination 
address for reaching said destination address. 

45 [0021] In this context, a VPN device related to a des- 
tination address refers to the VPN device, which is se- 
curing the site, to which the destination address be- 
longs. In order to communicate to the destination ad- 
dress, a VPN tunnel needs to be created to this VPN 
so device. 

[0022] According to a fourth aspect of the invention a 
method for handling VPN configuration in a VPN Infor- 
mation Provider (VIP) comprises 

55 - maintaining VPN configurations of VPN devices be- 
longing to a first VPN, 

providing to VPN devices belonging to the first VPN, 
information about the VPN configurations main- 
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tained in the VIP, 

receiving from a first VPN device belonging to the 
first VPN, a request for VPN configuration of anoth- 
er VPN device belonging to the first VPN, and 
- sending to said first VPN device belonging to the 5 
first VPN, the VPN configuration of the other VPN 
device as a response to the request. 

[0023] According to the invention all entire encryption/ 
decryption load is addressed to the firewalls or security 10 
gateways protecting the sites, while the VPN adminis- 
tration is centralized by means of VI Ps to achieve con- 
sistent configuration at every site. Also there is no cen- 
tralized location where all the traffic is in cleartext form 
as in the central hub arrangement, so the communica- is 
tion is more secure than in a star like structure. 
[0024] The method of the invention enables flexible 
management of a VPN between several autonomous 
organizations. Additionally, providing VPN manage- 
ment as a service is enabled. That is, the invention offers 20 
MSPs (Managed Service Providers) a possibility to pro- 
vide a new type of service by means of VIPs. VPN con- 
figuration is managed separately from other configura- 
tion information and therefore management of VPN con- 
figuration can be securely outsourced and an organiza- 25 
tion can easily join different VPNs, which may be admin- 
istered by a plurality of different VIPs. 
[0025] These and other features of the invention, as 
well as the advantages offered thereby, are described 
hereinafter with reference to embodiments illustrated in 30 
the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0026] 35 

Figure 1 illustrates an example network topology, 
Figure 2 illustrates a star like VPN topology, 
Figures 3, 4 and 5 illustrate example network topol- 
ogies according to the invention, 40 
Figure 6 is a flow chart illustrating management of 
VPN devices according to an aspect of the inven- 
tion, 

Figure 7 is a flow chart illustrating management of 
VPN devices according to another aspect of the in- 45 
vention, and 

Figure 8 is a flow chart illustrating handling of VPN 
configuration in a VPN device according to still other 
aspect of the invention. 

50 

DETAILED DESCRIPTION OF THE INVENTION 

[0027] Figures 1 and 2 are discussed in more detail 
above in connection with the prior art description. 
[0028] In the following description the invention is 55 
mainly disclosed in connection with a VPN capable fire- 
wall implementation. However, the method of the inven- 
tion can be applied straightforwardly also in any security 



gateway without firewall functionality as well as in a VPN 
client solution, which provides VPN connectivity for a 
single (and often mobile) host. Additionally, the inven- 
tion can be used in connection with dynamic security 
gateway (gateways, which do not have a static IP-ad- 
dress). Therefore, the invention can be employed in any 
device acting as an endpoint of a VPN. 
[0029] According to one aspect of the invention VPN 
device's own VPN configuration is defined and main- 
tained in a local management system, or in MSP's man- 
agement system, if the VPN device is administered by 
an MSP. The VPN configuration may be defined togeth- 
er with access rule configuration of the VPN device, if 
the VPN device acts as a firewall. However, the VPN 
device may be only a simple encryption/decryption end- 
point of a VPN without firewall functionality. When the 
site behind the VPN device wants to join for example 
VPN1 , the VPN configuration of the VPN device is pro- 
vided to VIP1, which is managing VPN1. Alternatively, 
the VPN configuration may be provided to the gateway 
from the VIP1. 

[0030] VIP1 provides the VPN device with VPN con- 
figurations of other endpoints belonging to VPN1 or in- 
formation about the configuration of the VPN1 as a 
whole. In the former case, the VPN device uses the con- 
figuration normally for communicating over VPN1 and 
VIP1 takes care of that the configuration, which the VPN 
device has, is up-to-date. In the latter case, the VPN 
device queries the actual configuration from the VIP1 
when needed. 

[0031] It must be appreciated that the arrangement of 
the invention does not compromise security of the 
VPNs, even though the VPN configuration information 
of all sites is available from a central point (VIP). The 
configuration includes the authentication keys of the 
sites, that is the end points of the VPNs, but in VPN each 
connection is encrypted with connection specific keys, 
which are negotiated between the communicating sites, 
and thus knowing the authentication key of a site does 
not enable breaking into a VPN connection. 
[0032] Figure 3 illustrates an example network topol- 
ogy according to one aspect of the invention. The sites 
of the Figure 1 are secured by security gateways 
301-304, which include the VPN configuration related to 
the VPN between the sites for other sites as in prior art. 
Thus, the security gateways are taking care of all en- 
cryption tasks. However, now the local management 
systems 305-308 do not take care of providing the VPN 
configuration to the security gateways. VPN configura- 
tion information of the sites is loaded to the security 
gateways from a VPN Information Provider (VIP) 300. 
It must be noted herein, that even though only one VIP 
is shown in the Figure, VPN configuration for some other 
VPN may be loaded to the security gateways from some 
other VIP, and that the number of different VPN config- 
urations and VIPs used is not restricted. 
[0033] When configuration of one site is changed the 
change needs to be done only in the VIP from which the 
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updated configuration is then loaded to security gate- 
ways of all sites. The VIP loads the configuration to the 
security gateways for example every time after a change 
occurs in the configuration. The change may be an ad- 
dition or removal of a site or modification of some site's 5 
configuration. In addition, the VIP may push the config- 
uration information to the security gateways after certain 
time interval has elapsed since the configuration was 
pushed the last time in order to minimize the possibility 
that the sites would not have up-to-date configuration. 10 
The security gateways use the VPN configuration load- 
ed from the VIP in the same way, as they would use 
configuration loaded from a local management system. 
The security gateways basically need to be configured 
to accept configuration from the VIP, but otherwise their 15 
operation does not need to be altered. The communica- 
tion between the VIP and the security gateways is en- 
crypted by some suitable means; for example Secure 
Sockets Layer (SSL) protocol may be used for this. In 
addition to this some parts of the configuration of the 20 
security gateways, e.g. configuration not related to the 
VPNs, and/or possible access rules related to the VPN 
are managed from site-specific local management sys- 
tems 305-308. 

[0034] Instead of pushing the whole configuration to 25 
the security gateways after every change, the VIP may 
push only indication that the configuration has changed 
and the security gateway may initiate the transfer of up- 
dated configuration from the VIP to the security gate- 
way. 30 
[0035] Figure 4 illustrates an example network topol- 
ogy according to another aspect of the invention. Here 
three sites are secured by means of security gateways 
404-406, out of which security gateway 404 is managed 
from a local management 403 and security gateways 35 
405 and 406 are managed from MSP's management 
system 402. Naturally MSP's management connection 
to the security gateways 405 and 406 does not need to 
be over the Internet as shown in the Figure, but can be 
for example leased line. Security gateways of sites 1 40 
and 2, which join in VPN1, are provided with identifica- 
tion information for VIP1 400 (VIP identification is de- 
fined in a local management or in MSPs management 
system), which is administering VPN1 . The sites receive 
VPN configuration for VPN 1 from VIP1 . Equally, security 45 
gateways of sites 2 and 3, which join in VPN2, are pro- 
vided with identification information for VIP2 401 , which 
is administering VPN2, and receive VPN configuration 
for VPN2 from VIP2. Thus, security gateway 405 of site 
2 has identification information for both VIP1 and VIP2. so 
When a security gateway detects a packet, which is des- 
tined to a host in a VPN the security gateway belongs 
to, the security gateway queries VPN configuration 
needed for establishing a VPN tunnel for reaching the 
host. 55 
[0036] In this scenario, all VPN configurations are not 
distributed to the security gateways. Instead, the secu- 
rity gateways query the configuration from the VIP when 



needed. In order to be able to query configuration, the 
security gateways need to know from which VI P to query 
it. For this purpose, the VIPs send to security gateways 
information about the configurations they have. This in- 
formation may be for example a list of lP-addresses in- 
cluded in the VPN or list of VPN sites included in the 
VPN. In principle this means the addresses, which can 
be reached over by means of the respective VPN. In the 
latter case the specific other endpoint (other VPN device 
and its configuration) to which a certain VPN tunnel 
should be destined is provided to a security gateway on- 
ly when needed. The benefit of this solution is that small- 
er amount of data needs to be distributed to the security 
gateways. Since it is likely that in many VPN's all gate- 
ways do not communicate with all other gateways, all 
gateways do not necessarily need configuration for all 
possible other endpoints. Moreover, only fundamental 
changes in the configuration of the whole VPN trigger 
the need to distribute data to all security gateways. 
Since configuration of a gateway is queried from the VIP 
before use, minor changes in configuration of one se- 
curity gateway do not need to be immediately commu- 
nicated to all other security gateways. Only if a new site 
is added or removed from the VPN, i.e. the address 
range of the VPN changes, all security gateways need 
to be informed of the change. 

[0037] In addition, this arrangement enables the use 
of dynamic security gateways. If a security gateway ob- 
tains its address dynamically, for example from a DHCP 
(Dynamic Host Configuration Protocol) server, other 
gateways cannot know from which address the dynamic 
security gateway is reached at a given time. Now, ad- 
dresses behind the dynamic security gateway can be 
maintained in a VIP and conveyed to other gateways 
from there. Then the dynamic security gateway informs 
the VIP of its current address every time its address 
changes. The VIP then conveys the current address to 
another gateway when needed (other gateways query 
the current address on the basis of an address included 
in the site of the dynamic gateway). Since the address 
of a dynamic gateway may change at any given time, e. 
g. due to connectivity failures, and other gateways may 
cache configurations received from a VIP for future use, 
there is a possibility that a security gateway has an out- 
of-date configuration for a dynamic gateway. Therefore, 
it is beneficial that the VIP tags the configuration of a 
dynamic security gateway differently from static config- 
urations. In this way, a security gateway can for example 
adjust the time a configuration of a dynamic gateway is 
cached or otherwise treat dynamic and static entries dif- 
ferently. 

[0038] Figure 5 illustrates an example network topol- 
ogy according to still other aspect of the invention. 
Therein security gateways 503 and 506 of sites 1 and 3 
are managed by local management 504 and MSP 502, 
respectively. VPN configurations of the security gate- 
ways defined in the local management or MSP. The con- 
figurations are provided to a VIP 500 and maintained 
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therein. It should be noted herein that when the VIP re- 
ceives VPN configuration of a security gateway, it could 
check if the configuration is compatible with VPN policy 
of the VIP and with VPN configurations of the other se- 
curity gateways belonging to the VPN. This can be done 
by simply comparing the new configuration to configu- 
rations of other gateways. When the security gateways 
are establishing a VPN tunnel they first query the con- 
figuration of the other endpoint from the VIP. (This is de- 
scribed in more detail above in connection with Figure 
4.) 

[0039] In addition to the sites 1 and 3 belonging to the 
VPN, there is a VPN client 505 joining in the VPN as 
well. The VPN configuration of the VPN client is main- 
tained in the VIP in similar way as the configurations of 
the dynamic security gateways. 
[0040] The example implementations of the invention 
illustrated in Figures 3 to 5 are not meant to be restric- 
tive. Instead, implementation details related to one ex- 
ample may be combined to the details of another exam- 
ple in any suitable way. 

[0041] The VIP and the VPN devices (security gate- 
ways, firewalls, VPN clients) according to the invention 
may be implemented as a suitable combination of hard- 
ware and software. Typically the implementation is soft- 
ware program code executed in a processor unit com- 
bined with suitable memory resources. 
[0042] A major part of the implementation of the in- 
vention is a change in the handling of the configuration 
in the VPN device. A VPN device according to the in- 
vention is adapted to receive configuration from more 
than one management entity, e.g. from a local manage- 
ment and a VIP. In general VIP provides VPN configu- 
ration and local management provides access rule con- 
figuration. However, local management may provide 
VPN configuration as well. The VPN device is adapted 
to identify different VIP for example by means of certif- 
icates. In addition, VPN device may check, if a VPN con- 
figuration received from a VIP is in accordance with oth- 
er configuration of the VPN device, before accepting the 
configuration for use. 

[0043] A VIP can be basically similar to a centralized 
VPN management system able to handle VPN devices; 
the VIP includes thus capability to define VPN configu- 
rations and to upload them to the VPN devices. Alterna- 
tively, a VIP may accept readily defined VPN configura- 
tions for maintenance. In this case the VIP administering 
a VPN is preferably adapted to confirm that a received 
new configuration is compatible with the configurations 
of other gateways belonging to the VPN. In addition a 
VIP according to one aspect of the invention comprises 
mechanism for providing VPN devices with information 
about the configurations maintained in the VIP and 
sending configuration to VPN devices on demand, that 
is, as a response to a request. 
[0044] Features of the invention are further illustrated 
in the flow charts of Figures 6, 7 and 8. Figure 6 is a flow 
chart illustrating management of VPN devices accord- 



ing to an aspect of the invention. In steps 600 and 602, 
VPN configurations are defined for VPN devices and the 
configurations are maintained in a VIP. The VPN config- 
uration of a given VPN device may be defined in the VIP 
5 or in some other management system, from where the 
configuration is provided to the VIP for maintenance. 
Then in step 604, a VPN device is provided with VPN 
configuration of some other VPN device by means of 
sending the configuration from the VIP. In step 606 cer- 
10 tain aspects of the VPN devices are managed from 
some other management system. Such aspects may be 
for example access rule configurations or configurations 
related to some other VPN configuration. 
[0045] Figure 7 is a flow chart illustrating manage- 
rs mentofVPN devices according to another aspect of the 
invention. Therein, VPN configurations are defined for 
VPN devices belonging to first and second VPNs in step 
700. The configurations for the first VPN are maintained 
in a first VIP and the configurations for the second VPN 
20 are maintained in a second VIP in steps 702 and 704 
respectively. Also in this case the VPN configuration of 
a given VPN device may be defined in a VIP or in some 
other management system, from where the configura- 
tion is provided to the respective VIP for maintenance. 
25 Then in step 706, a VPN device belonging to the first 
and second VPNs obtains VPN configuration of at least 
one other VPN device belonging to the first VPN from 
the first VIP and VPN configuration of at least one other 
VPN device belonging to the second VPN from the sec- 
30 ond VIP. 

[0046] Figure 8 is a flow chart illustrating handling of 
VPN configuration in a VPN device according to still oth- 
er aspect of the invention. In step 800, the VPN device 
receives information about the VPN configurations 

35 maintained in a VIP (e.g. set of addresses included in 
the respective VPN). Then the VPN device receives a 
data packet destined to the VPN in step 802. On the 
basis of the information received from the VIP the VPN 
device queries VPN configuration from the VIP in step 

40 804 and uses VPN configuration obtained from the VIP 
for establishing a VPN tunnel for the data packet. 
[0047] It will be apparent for those skilled in the art 
that the illustrative embodiments described are only ex- 
amples and that various modifications can be made 

45 within the scope of the invention as defined in the ap- 
pended claims. 

Claims 

50 

1. A method for managing VPN devices, character- 
ized in that the method comprises the steps of 

maintaining (602) in a VPN Information Provid- 
55 er (VIP) VPN configurations of VPN devices be- 

longing to a first VPN, 

providing (604) from the VIP to a first VPN de- 
vice belonging to the first VPN, VPN configura- 
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tion of at least one other VPN device belonging 
to the first VPN, and 

managing (606) certain aspects of said first 
VPN device belonging to the first VPN from at 
least one other management system. 

2. A method as claimed in claim 1, characterized in 
that said configuration of at least one other VPN 
device is provided to said first VPN device via said 
at least one other management system. 

3. A method as claimed in claim 1, characterized in 
that said configuration of at least one other VPN 
device is provided directly to said first VPN device. 

4. A method as claimed in any one of claims 1 to 3, 
characterized by further comprising 

defining (600) said VPN configurations of said 
VPN devices belonging to the first VPN in said 
at least one other management system, and 
providing said VPN configurations to the VIP for 
maintenance. 

5. A method as claimed in any one of claims 1 to 3, 
characterized by further comprising 

defining (600) said VPN configurations of said 
VPN devices belonging to the first VPN in the 
VIP, and 

providing said VPN configurations to respective 
VPN devices. 

6. A method as claimed in any one of claims 1 to 5, 
characterized in that the step of providing com- 
prises 

sending to VPN devices belonging to the first 
VPN, information about the VPN configurations 
maintained in the VIP, 

receiving from a first VPN device belonging to 
the first VPN, a request for VPN configuration 
of another VPN device belonging to the first 
VPN, and 

sending to said first VPN device belonging to 
the first VPN, the VPN configuration of the other 
VPN device as a response to the request. 

7. A method as claimed in claim 6, characterized in 
that said information about the VPN configurations 
maintained in the VIP is a set of addresses included 
in the first VPN, said request from the first VPN de- 
vice comprises an address included in the first VPN, 
and said other VPN device is identified in the VIP 
by finding a VPN device related to said address. 

8. A method as claimed in claim 6, characterized in 
that said information about the VPN configurations 



maintained in the VIP is a set of addresses included 
in the first VPN, and said information is sent after a 
change in the set of addresses included in the first 
VPN, or after a predefined time has elapsed since 
5 the information was sent the last time. 

9. A method as claimed in any one of claims 1 to 5, 
characterized in that the step of providing com- 
prises 

10 

- sending to VPN devices belonging to the first 
VPN, VPN configurations maintained in the 
VIP. 

15 10. A method as claimed in claim 9, characterized in 
that said VPN configurations maintained in the VIP 
are sent after a new VPN configuration has been 
added to the VIP, after an old VPN configuration has 
been removed from the VIP, after a VPN configura- 

20 tion of at least one VPN device has been changed 
in the VIP, or after a predefined time has elapsed 
since the configurations were sent the last time. 

11. A method for managing VPN devices, character- 
25 ized in that the method comprises the steps of 

maintaining (702) in a first VPN Information 
Provider (VIP) VPN configurations of VPN de- 
vices belonging to a first VPN, 

30 - maintaining (704) in a second VPN Information 
Provider (VIP) VPN configurations of VPN de- 
vices belonging to a second VPN, and 
providing (706) to a first VPN device belonging 
to the first and second VPNs, VPN configura- 

35 tion of at least one other VPN device belonging 

to the first VPN from the first VIP and VPN con- 
figuration of at least one other VPN device be- 
longing to the second VPN from the second 
VIP. 

40 

12. A method as claimed in claim 11, characterized in 
that said configuration of at least one other VPN 
device is provided to said first VPN device via at 
least one other management system. 

45 

13. A method as claimed in claim 11, characterized in 
that said configuration of at least one other VPN 
device is provided directly to said first VPN device. 

so 14. A method as claimed in any one of claims 11 to 13, 
characterized by further comprising 

defining (700) said VPN configurations of said 
VPN devices belonging to the first and second 
55 VPNs in at least one other management sys- 

tem, and 

providing said VPN configurations to the VIPs 
for maintenance. 
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15. A method as claimed in any one of claims 11 to 13, 
characterized by further comprising 

defining (700) said VPN configurations of said 
VPN devices belonging to the first VPN in the 
first VIP and said VPN configurations of said 
VPN devices belonging to the second VPN in 
the second VIP, and 
- providing said VPN configurations to respective 
VPN devices. 

16. A method as claimed in any one of claims 11 to 15, 
characterized in that the step of providing com- 
prises 

sending to VPN devices belonging to a VPN, 
information about the VPN configurations 
maintained in the respective VIP, 
receiving from a first VPN device belonging to 
the VPN, a requestfor VPN configuration of an- 
other VPN device belonging to the VPN, and 
sending to said first VPN device belonging to 
the VPN, the VPN configuration of the other 
VPN device as a response to the request. 

17. A method as claimed in claim 16, characterized in 
that said information about the VPN configurations 
maintained in the VIP is a set of addresses included 
in the first VPN, said request from the first VPN de- 
vice comprises an address included in the first VPN, 
and said other VPN device is identified in the VIP 
by finding a VPN device related to said address. 

18. A method as claimed in claim 16, characterized in 
that said information about the VPN configurations 
maintained in the VIP is a set of addresses included 
in the first VPN, and said information is sent after a 
change in the set of addresses included in the first 
VPN, or after a predefined time has elapsed since 
the information was sent the last time. 

19. A method as claimed in any one of claims 11 to 15, 
characterized in that the step of providing com- 
prises 

sending to VPN devices belonging to a VPN, 
VPN configurations maintained in the respec- 
tive VIP. 

20. A method as claimed in claim 19, characterized in 
that said VPN configurations maintained in the VIP 
are sent after a new VPN configuration has been 
added to the VIP, after an old VPN configuration has 
been removed from the VIP, after a VPN configura- 
tion of at least one VPN device has been changed 
in the VIP, or after a predefined time has elapsed 
since the configurations were sent the last time. 



21. A method for handling VPN configuration in a VPN 
device, the method comprising 

receiving (802) a packet directed to a destina- 
5 tion address in a first VPN, the method being 

characterized by 

requesting and receiving (804) VPN configura- 
tion for a VPN device related to said address 
from a VPN Information Provider (VIP) admin- 
10 istering the first VPN, and 

using (806) said VPN configuration for estab- 
lishing a VPN tunnel to said VPN device related 
to said destination address for reaching said 
destination address. 

15 

22. A method for handling VPN configuration in a VPN 
Information Provider (VIP), characterized in that 
the method comprises 

20 - maintaining VPN configurations of VPN devic- 
es belonging to a first VPN, 
providing to VPN devices belonging to the first 
VPN, information about the VPN configurations 
maintained in the VIP, 

25 - receiving from a first VPN device belonging to 
the first VPN, a request for VPN configuration 
of another VPN device belonging to the first 
VPN, and 

sending to said first VPN device belonging to 
30 the first VPN, the VPN configuration of the other 

VPN device as a response to the request. 

23. An arrangement for managing VPN devices com- 
prising 

35 

- at least two VPN devices (301-304, 404, 405, 
503, 505, 506) belonging to a first VPN, the ar- 
rangement being characterized by comprising 

- a VPN Information Provider (VIP) (300, 400, 
40 500) maintaining VPN configurations of VPN 

devices belonging to the first VPN, and 
at least one other management system 
(305-308, 402, 403, 502, 504) managing cer- 
tain aspects of said VPN devices belonging to 
45 the first VPN, while 

the VPN devices are adapted to receive from 
the at least one other management system, a first 
part of configuration, and from the VIP, a second 
so part of configuration, which comprises VPN config- 
uration of at least one other VPN device belonging 
to the first VPN. 

24. An arrangement as claimed in claim 23, character- 
55 ized in that the first part of configuration comprises 

VPN configuration and /or access rule configura- 
tion. 
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25. An arrangement for managing VPN devices, char- 
acterized by comprising 

at least two VPN Information Providers (VIP), 
a first one (400) maintaining VPN configura- 
tions of VPN devices belonging to a first VPN 
and a second one (401) maintaining VPN con- 
figurations of VPN devices belonging to a sec- 
ond VPN, and 

a VPN device (405) belonging to the first and 
second VPNs and receiving VPN configuration 
information from the first and second VIPs. 

26. A VPN device (301-304, 404, 405, 503, 505, 506) 
comprising 

a mechanism for receiving a packet directed to 
a destination address in a first VPN, the VPN 
device being characterized by comprising 
mechanisms for requesting and receiving VPN 
configuration for a VPN device related to said 
address from a VPN Information Provider (VIP) 
administering the first VPN, and 
a mechanism for using said VPN configuration 
for establishing a VPN tunnel to said VPN de- 
vice related to said destination address for 
reaching said destination address.. 

27. A VPN Information Provider (VIP) (300, 400, 401, 
500) characterized by comprising 

a mechanism for maintaining VPN configura- 
tions of VPN devices belonging to a first VPN, 
a mechanism for providing to VPN devices be- 
longing to the first VPN, information about the 
VPN configurations maintained in the VIP, 
a mechanism for receiving from a first VPN de- 
vice belonging to the first VPN, a request for 
VPN configuration of another VPN device be- 
longing to the first VPN, and 
a mechanism for sending to said first VPN de- 
vice belonging to the first VPN, the VPN con- 
figuration of the other VPN device as a re- 
sponse to the request. 

28. A computer-readable medium, comprising program 
code which, when executed on a computer device, 
causes the computer device to provide a VPN de- 
vice functionality comprising 

receiving a packet directed to a destination ad- 
dress in a first VPN, - requesting and receiving 
VPN configuration for a VPN device related to 
said addressfrom a VPN Information Provider 
(VIP) administering the first VPN, and 
using said VPN configuration for establishing a 
VPN tunnel to said VPN device related to said 
destination address for reaching said destina- 



tion address. 

29. A computer-readable medium comprising program 
code which, when executed on a computer device, 

5 causes the computer device to provide a VPN In- 
formation Provider (VIP) functionality comprising 

maintaining VPN configurations of VPN devic- 
es belonging to a first VPN, 
10 - providing to VPN devices belonging to the first 
VPN, information about the VPN configurations 
maintained in the VIP, 

receiving from a first VPN device belonging to 
the first VPN, a request for VPN configuration 
15 of another VPN device belonging to the first 

VPN, and 

sending to said first VPN device belonging to 
the first VPN, the VPN configuration of the other 
VPN device as a response to the request 

20 

30. A computer program code which, when executed 
on a computer device, causes the computer device 
to provide a VPN device functionality comprising 

25 - receiving a packet directed to a destination ad- 
dress in a first VPN, 

requesting and receiving VPN configuration for 
a VPN device related to said address from a 
VPN Information Provider (VIP) administering 
30 the first VPN, and 

using said VPN configuration for establishing a 
VPN tunnel to said VPN device related to said 
destination address for reaching said destina- 
tion address. 

35 

31. A computer program code which, when executed 
on a computer device, causes the computer device 
to provide a VPN Information Provider (VIP) func- 
tionality comprising 

40 

maintaining VPN configurations of VPN devic- 
es belonging to a first VPN, 
- providing to VPN devices belonging to the first 
VPN, information about the VPN configurations 
45 maintained in the VIP, 

receiving from a first VPN device belonging to 
the first VPN, a request for VPN configuration 
of another VPN device belonging to the first 
VPN, and 

50 - sending to said first VPN device belonging to 
the first VPN, the VPN configuration of the other 
VPN device as a response to the request. 
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